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REMARKS/ARGUMENTS 

Claims 16-23 are pending in the application. Claim 1 is canceled by the foregoing 
amendments. Claims 16 and 21 have been amended to more clearly indicate relationship of the 
elements of those claims. Applicants now address the previous rejection of these claims in the 
Final Office action mailed on July 2, 2003 in the parent application of the present application. 



Claim Rejections - 35 U.S.C. §103 

The Examiner has rejected claims 16-23 under 35 U.S.C. §103(a) as being unpatentable 
over U.S. Patent 6,501, 746 to Leung. This rejection is respectfully reversed. 
Claim 16 recites: 

In a communication system for communicating with a plurality of mobile 
nodes, the system managing Internet Protocol (IP) addresses in multiple address 
pools, the multiple pools having overlapping IP addresses and each pool being 
associated with a unique home agent IP address, a method comprising: 

assigning a home IP address to a given mobile node from one of the 
multiple pools; and, 

in a mobility agent, using a combination of the assigned home IP 
address of the given mobile node and an IP address of a home agent to 
uniquely identify the given mobile node. 

The Examiner asserts that Leung discloses a method and system for communicating with 

a plurality of mobile nodes, the system managing Internet Protocol (IP) addresses in multiple 

address pools, the multiple pools having overlapping IP addresses. Applicants respectfully 

disagree with this assertion by the Examiner. While Leung describes assigning IP addresses 

from a pool, Leung contains no teaching, suggestion or disclosure of a system and method where 

IP addresses are assigned from multiple pools having overlapping IP addresses. For example, 

Leung states in his SUMMARY at column 3, lines 36-41 : 

The present invention may be used to temporarily assign an DP address to a mobile 
node on an as-needed basis. In this manner, a pool of IP addresses may be 
advantageously distributed to preserve the pool of IP addresses. Accordingly, the 
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present invention permits an entity to economically utilize a limited number of IP 
addresses. 

While Leung describes assigning IP addresses from a pool, it contains no teaching that the IP 
addresses in the pool are overlapping. This is particularly relevant, because if overlapping 
addresses were employed in the address pool of the system and method of Leung, that system 
and method would potentially not function as two mobile nodes could be assigned the same IP 
(overlapping) address, which would result in packet routing errors due to the presence of 
identical IP addresses on the Internet with no mechanism for distinguishing between such mobile 
nodes. 

The Examiner further asserts that Leung discloses using a combination of an assigned 
Home IP Address of the given mobile node and an IP address of a Home Agent to uniquely 
identify the given mobile node in a mobility agent. Applicants also respectfully disagree with 
this assertion of the Examiner. In this regard, the Examiner relies on Leung column 9, lines 42- 
62, which recites: 

FIG. 4 is a diagram illustrating a registration reply having a Home Address ID 
extension that may be sent by a Home Agent in accordance with an embodiment 
of the invention. As shown, the fixed length portion 402 of the registration reply 
includes a Type field 404 that identifies the message as either a Registration 
Request (1) or a Registration Reply (3). In addition, a Code field 406 tells the 
mobile node whether its attempted registration was accepted or rejected. A 
Lifetime field 408 in the registration reply tells the mobile node how long the 
registration lasts before it expires. In addition, the registration reply includes 
the mobile node's Home Address 410 and the Home Agent Address 412. The 
Identification field 414 is chosen by the mobile node to be unique for each 
registration. This allows the mobile node to match Registration Requests with the 
corresponding Registration Replies. In addition, this may be used to prevent a 
third party from capturing the registration request and replaying it at a later time. 
As described above, the registration reply may include a Home Address ID 
extension 416 which is capable of storing the IP address, or Home Address 418, 
that is assigned to the mobile node during registration. {Emphasis supplied) 

The Examiner appears to be relying on the statement in Leung that a registration reply includes a 
Home Address 410 and a Home Agent Address 412 to teach the aspect of claim 1 that a 
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combination of an assigned home IP address of the given mobile node and an IP address of 
a Home Agent to uniquely identify the given mobile node in a mobility agent. What Leung 
is in fact stating is part of the Mobile IP standard, IP Mobility Support, RFC 2002, The Internet 
Engineer Task Force, October 1996. For the Examiner's convenience, relevant portions of this 
standard are attached as Exhibit A. As may be seen in section 3.4 of the RFC 2002, the User 
Datagram Protocol (UDP) header for a registration supply includes, among other things, a Home 
Address and a Home Agent Address. The registration reply, however, is merely a response to 
the registration request from a mobile node and the UDP header of the registration reply is not 
used to uniquely identify the given mobile node in a mobility agent, contrary to the Examiner's 
request. 

Also consistent with the RFC 2002, Leung uses a Mobile Host Table to identify data 
session (e.g., a point-to-point protocol session) associated with a particular mobile node. Such a 
Mobile Host Table 702 is illustrated in Fig. 7 of Leung, which is included below for the 
Examiner's convenience. 
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Leung describes this table in column 10, line 58 through column 11, line 5, which recites: 

FIG. 7 is a diagram illustrating an exemplary mobile host table that may be used 
by an active Home Agent in accordance with an embodiment of the invention. As 
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shown, the mobile host table 702 provides a list of mobile nodes that the Home 
Agent supports such that each of the mobile nodes is associated with a 
corresponding IP address when actively roaming. The mobile host table 702, as 
shown, includes an entry 704 for one or more mobile nodes that are supported by 
the Home Agent. Each of these entries 704 includes a mobile node ID 706 
associated with one of the mobile nodes. Such an association may be 
accomplished by including an IP address 708 associated with the mobile 
node. By way of example, the IP address 708 may be a configured Home 
Address or an IP address allocated from the pool of IP addresses. (Emphasis 
supplied) 

As may be seen from this portion of Leung, a mobile node with a mobile ID 706 is identified in 



the Mobile Host Table 702 by including an EP Address in the Table 702. The IP address may be 



a configured Home address or an IP Address allocated from the pool (non-overlapping, as 



discussed above) of IP address. This approach is completely consistent with section 4.2.2 RFC 



2002, which describes using a Home Address (inner destination address) to identify a mobile 



node in a visitor list (such as Leung's Mobile Host Table 702), but not does not describe using 



the Home Agent Address in conjunction with the Home Address. Thus, Leung does not teach, 



suggest or described identifying a mobile node with an assigned home IP address of the given 



mobile node and an IP address of a Home Agent to uniquely identify the given mobile node, 



as is recited in claim 16. 



Because Leung fails to teach suggest or describe using the combination of a Home 



Address and a Home Agent Address to uniquely identify a mobile node and the use of multiple 



address pools having overlapping addresses, it does not render claim 16 obvious. Therefore, the 



previous rejection of claim 1 is overcome and that claim is allowable. 



Claims 17-23 depend ultimately from claim 16 and include all the limitations of claim 16 



and any intervening claims. Therefore, claims 17-23 are allowable on at least the same basis as 



claim 16. Thus, claims 17-23 are also allowable. 
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Conclusion 

In view of the foregoing, all of the claims, as amended, pending in this patent application 
are in condition for allowance. If the Examiner has any questions, he is invited to contact the 
undersigned at (360) 379-65 14. An early allowance of all the claims is respectfully requested. 



Respectfully Submitted, 



Date: if**. /? 1 JoW 



CERTIFICATE OF MAILING UNDER 37 C.F.R. § 1.8 

The undersigned hereby certifies that the foregoing SUPPLEMENTAL PRELIMINARY 
AMENDMENT with attached Exhibit A is being deposited as first class mail, postage prepaid, in 
an envelope addressed to Mail Stop Non-Fee Amendment, Commissioner for Patents, P.O. Box 
1450, Alexandria, VA 22313-1450 on this 13th day of January 2004. 

(pLt^. A-=z 

Paul W. Churilla 



By: 



McDonnell Boehnen Hulbert & Berghoff 



Paul W. Churilla 
Reg. No. 47,495 
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3.4. Registration Reply 

A mobility agent returns a Registration Reply message to a mobile 
node which has sent a Registration Request (Section 3.3) message. If 
the mobile node is requesting service from a foreign agent, that 
foreign agent will receive the Reply from the home agent and 



subsequently relay it to the mobile node. The Reply message contains 
the necessary codes to inform the mobile node about the status of its 
Request, along with the lifetime granted by the home agent, which MAY 
be smaller than the original Request. 

The foreign agent MUST NOT increase the Lifetime selected by the 
mobile node in the Registration Request, since the Lifetime is 
covered by the Mobile -Home Authentication Extension, which cannot be 
correctly (re) computed by the foreign agent. The home agent MUST NOT 
increase the Lifetime selected by the mobile node in the Registration 
Request, since doing so could increase it beyond the maximum 
Registration Lifetime allowed by the foreign agent. If the Lifetime 
received in the Registration Reply is greater than that in the 
Registration Request, the Lifetime in the Request MUST be used. When 
the Lifetime received in the Registration Reply is less than that in 
the Registration Request, the Lifetime in the Reply MUST be used. 

IP fields: 

Source Address Typically copied from the destination 



Destination Address Copied from the source address of the 

Registration Request to which the agent is 
replying 



address of the Registration Request to which 
the agent is replying. See Sections 3.7.2.3 
and 3.8.3.1 for complete details. 



UDP fields: 



Source Port 



<variable> 



Destination Port 



Copied from the source port of the 
corresponding Registration Request 
(Section 3.7.1) . 
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The UDP header is followed by the Mobile IP fields shown below: 

0 12 3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Code | Lifetime | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
j Home Address | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Home Agent | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 



+ - Identification 



+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Extensions . . . 

+-+-+-+-+-+-+-+- 

Type 3 (Registration Reply) 

Code A value indicating the result of the Registration 

Request. See below for a list of currently defined Code 
values . 

Lifetime 

If the Code field indicates that the registration was 
accepted, the Lifetime field is set to the number of 
seconds remaining before the registration is considered 
expired. A value of zero indicates that the mobile node 
has been deregistered. A value of Oxffff indicates 
infinity. If the Code field indicates that the 
registration was denied, the contents of the Lifetime 
field are unspecified and MUST be ignored on reception. 

Home Address 

The IP address of the mobile node. 

Home Agent 

The IP address of the mobile node's home agent. 
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Identification 

A 64 -bit number used for matching Registration Requests 
with Registration Replies, and for protecting against 
replay attacks of registration messages. The value is 
based on the Identification field from the Registration 
Request message from the mobile node, and on the style of 
replay protection used in the security context between 
the mobile node and its home agent (defined by the 
mobility security association between them, and SPI 
value in the Mobile-Home Authentication Extension) . See 
Sections 5.4 and 5.6. 

Extensions 

The fixed portion of the Registration Reply is followed 
by one or more of the Extensions listed in Section 3.5. 
The Mobile -Home Authentication Extension MUST be included 
in all Registration Replies returned by the home agent. 
See Sections 3.7.2.2 and 3.8.3.3 for rules on placement 
of extensions to Reply messages. 

The following values are defined for use within the Code field. 
Registration successful: 

0 registration accepted 

1 registration accepted, but simultaneous mobility 
bindings unsupported 

Registration denied by the foreign agent: 

64 reason unspecified 

65 administratively prohibited 

66 insufficient resources 

67 mobile node failed authentication 

68 home agent failed authentication 

69 requested Lifetime too long 

70 poorly formed Request 

71 poorly formed Reply 

72 requested encapsulation unavailable 

73 requested Van Jacobson compression unavailable 
8 0 home network unreachable (ICMP error received) 

81 home agent host unreachable (ICMP error received) 

82 home agent port unreachable (ICMP error received) 
88 home agent unreachable (other ICMP error received) 
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Registration denied by the home agent: 

128 reason unspecified 

129 administratively prohibited 

130 insufficient resources 

131 mobile node failed authentication 

132 foreign agent failed authentication 

133 registration Identification mismatch 

134 poorly formed Request 

135 too many simultaneous mobility bindings 

136 unknown home agent address 

Up-to-date values of the Code field are specified in the most recent 
"Assigned Numbers" [2 0] . 

3.7.3. Receiving Registration Replies 

The foreign agent updates its visitor list when it receives a valid 
Registration Reply from a home agent. It then relays the 
Registration Reply to the mobile node. The following sections 
describe this behavior in more detail. 

If upon relaying a Registration Request to a home agent, the foreign 
agent receives an ICMP error message instead of a Registration Reply, 
then the foreign agent SHOULD send to the mobile node a Registration 
Reply with an appropriate "Home Agent Unreachable" failure Code 
(within the range 80-95, inclusive). See Section 3.7.2.3 for details 
on building the Registration Reply. 

3.7.3.1. Validity Checks 

Registration Replies with an invalid, non-zero UDP checksum MUST be 
silently discarded. 

When a foreign agent receives a Registration Reply message, it MUST 
search its visitor list for a pending Registration Request with the 
same mobile node home address as indicated in the Reply. If no 
pending Request is found, the foreign agent MUST silently discard the 
Reply. The foreign agent MUST also silently discard the Reply if the 
low-order 32 bits of the Identification field in the Reply do not 
match those in the Request . 

Also, the authentication in the Registration Reply MUST be checked. 
If the foreign agent and the home agent share a mobility security 
association, exactly one Foreign-Home Authentication Extension MUST 
be present in the Registration Reply, and the foreign agent MUST 
check the Authenticator value in the Extension. If no Foreign-Home 
Authentication Extension is found, or if more than one Foreign-Home 
Authentication Extension is found, or if the Authenticator is 
invalid, the foreign agent MUST silently discard the Reply and SHOULD 
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log the event as a security exception. The foreign agent also MUST 
reject the mobile node's registration and SHOULD send a Registration 
Reply to the mobile node with Code 68. 

3.7.3.2. Forwarding Replies to the Mobile Node 

A Registration Reply which satisfies the validity checks of Section 
3.8.2.1 is relayed to the mobile node. The foreign agent MUST also 
update its visitor list entry for the mobile node to reflect the 
results of the Registration Request, as indicated by the Code field 
in the Reply. If the Code indicates that the mobile node has 
accepted the registration and the Lifetime field is nonzero, the 
foreign agent MUST set the Lifetime in the visitor list entry to the 
value specified in the Lifetime field of the Registration Reply. If, 
instead, the Code indicates that the Lifetime field is zero, the 
foreign agent MUST delete its visitor list entry for the mobile node. 
Finally, if the Code indicates that the registration was denied by 
the home agent, the foreign agent MUST delete its pending 
registration list entry, but not its visitor list entry, for the 
mobile node. 

The foreign agent MUST NOT modify any of the fields beginning with 
the fixed portion of the Registration Reply up through and including 
the Mobile-Home Authentication Extension. Otherwise, an 
authentication failure is very likely to occur at the mobile node. 
In addition, the foreign agent SHOULD perform the following 
additional procedures: 

- It MUST process and remove any Extensions following the 
Mobile-Home Authentication Extension, 

- It MAY append its own non-authentication Extensions of relevance 
to the mobile node, if applicable, and 

- It MUST append the Mobile-Foreign Authentication Extension, if 
the foreign agent shares a mobility security association with the 
mobile node. 

Specific fields within the IP header and the UDP header of the 
relayed Registration Reply are set according to the same rules 
specified in Section 3.7.2.3. 

After forwarding a valid Registration Reply to the mobile node, the 
foreign agent MUST update its visitor list entry for this 
registration as follows. If the Registration Reply indicates that 
the registration was accepted by the home agent, the foreign agent 
resets its timer of the lifetime of the registration to the Lifetime 
granted in the Registration Reply; unlike the mobile node's timing of 
the registration lifetime as described in Section 3.6.2.2, the 
foreign agent considers this lifetime to begin when it forwards the 
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Registration Reply message, ensuring that the foreign agent will not 
expire the registration before the mobile node does. On the other 
hand, if the Registration Reply indicates that the registration was 
rejected by the home agent, the foreign agent deletes its visitor 
list entry for this attempted registration. 

4.2.2. Foreign Agent Considerations 

Upon receipt of an encapsulated datagram sent to its advertised 
care-of address, a foreign agent MUST compare the inner destination 
address to those entries, in its visitor list. When the destination 
does not match the address of any mobile node currently in the 
visitor list, the foreign agent MUST NOT forward the datagram without 
modifications to the original IP header, because otherwise a routing 
loop is likely to result. The datagram SHOULD be silently discarded. 
ICMP Destination Unreachable MUST NOT be sent when a foreign agent is 
unable to forward an incoming tunneled datagram. Otherwise, the 
foreign agent forwards the decapsulated datagram to the mobile node. 

The foreign agent MUST NOT advertise to other routers in its routing 
domain, nor to any other mobile node, the presence of a mobile router 
(Section 4.5). 

The foreign agent MUST route datagrams it receives from registered 
mobile nodes. At a minimum, this means that the foreign agent must 
verify the IP Header Checksum, decrement the IP Time To Live, 
recompute the IP Header Checksum, and forward such datagrams to a 
default router. In addition, the foreign agent SHOULD send an 
appropriate ICMP Redirect message to the mobile node. 



